There are two changes bundled together in this PR.

First, there is the extraction of b := *r.buf. Does this produce any faster code? I would have expected the compiler to make that transformation itself if it was helpful.

Second, there is the change of when the buffer is reset. For this change, I'd also like to know if there is any measurable difference in performance. The buffer is set to the same size as the PostgreSQL send buffer. In addition, previous testing did not reveal any advantage to a larger buffer. The only time this buffer would overflow is when an individual message is larger than 8KB. That should be quite rare. The only time I would expect this to happen enough that it might make a difference is a query that returns many, wide rows. I wouldn't mind an optimization for this case, but only if it can be shown to make a difference.

But if it does make a difference, then I would suggest another approach for choosing when to reset. I would say, only reset when there have been 2 reads in a row that are less than minBufSize. A successful query ends with a CommandComplete message. The CommandComplete message will be read with 2 calls to Next(). One for the size and type of the message and one for the body of the message. Both reads should be short. This would mean that there is no memory buffer churn when reading multiple large rows sequentially, but that the buffer is immediately freed when the the query is completed. But again, I would only want to make a change if a measurable improvement in a realistic scenario.